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Further Key Words for Use in RFCs to Indicate Requirement Levels 
Abstract 


RFC 2119 defines a standard set of key words for describing 
requirements of a specification. Many IETF documents have found that 
these words cannot accurately capture the nuanced requirements of 
their specification. This document defines additional key words that 
can be used to address alternative requirements scenarios. Authors 
who follow these guidelines should incorporate this phrase near the 
beginning of their document: 


The key words "MUST (BUT WE KNOW YOU WON’T)", "SHOULD CONSIDER", 
"REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", 
"COULD", "POSSIBLE", and "MIGHT" in this document are to be 
interpreted as described in RFC 6919. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for examination, experimental implementation, and 
evaluation. 


This document defines an Experimental Protocol for the Internet 
community. This is a contribution to the RFC Series, independently 
of any other RFC stream. The RFC Editor has chosen to publish this 
document at its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6919. 
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Copyright Notice 


Copyright (c) 2013 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. 
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Les 


MUST (BUT WE KNOW YOU WON’ T) 


The phrase "MUST (BUT WE KNOW YOU WON'T)" is used to indicate 
requirements that are needed to meet formal review criteria (e.g., 
mandatory-to-implement security mechanisms), when these mechanisms 
are too inconvenient for implementers to actually implement. 


This phrase is frequently used in a contracted form in which the 
parenthetical is omitted. The parenthetical may also be moved later 
in the sentence for stylistic reasons. If the parenthetical is 
present, authors MUST provide a reason why they know implementors 
will not heed this instruction in the parenthetical, as in the 
example (BUT WE KNOW YOU WON’T). In the below example, we show a 
case from RFC 6120 where the original text omitted the parenthetical, 
and we have indicated an appropriate parenthetical. 


For example: "For authentication only, servers and clients MUST 
support the SASL Salted Challenge Response Authentication Mechanism 


[SCRAM] -- in particular, the SCRAM-SHA-1 and SCRAM-SHA-1-PLUS 
variants [(BUT WE KNOW YOU WON’T, because your TLS library doesn’t 
support extracting channel binding information)]." [RFC6120] 


SHOULD CONSIDER 


The phrase "SHOULD CONSIDER" indicates that the authors of the 
specification think that implementations should do something, but 
they’ re not sure quite what. 


For example: "Applications that take advantage of typed links should 
consider the attack vectors opened by automatically following, 
trusting, or otherwise using links gathered from HTTP headers." 
[RFC5988] 


REALLY SHOULD NOT 
The phrase "REALLY SHOULD NOT" is used to indicate dangerous 


behaviors that some important vendor still does and therefore we were 
unable to make MUST NOT. 


For example: "This command really should not be used" [RFC0493] 
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OUGHT TO 


The phrase "OUGHT TO" conveys an optimistic assertion of an 
implementation behavior that is clearly morally right, and thus does 
not require substantiation. 


For example: "If a decision might affect semantic transparency, the 
implementor ought to err on the side of maintaining transparency 
unless a careful and complete analysis shows significant benefits in 
breaking transparency." [RFC2616] 


WOULD PROBABLY 


The phrase "WOULD PROBABLY" indicates the authors expectation about 
what a reasonable implementation is likely to do in a given case. 
There is no requirement for implementations to be reasonable. 


This phrase is also a good example of an aspect of English grammar 
that is often useful in specification writing, namely the passive- 
aggressive voice, which provides a meaning in between the active and 
the passive voice. 


For example: "A SMTP client would probably only want to authenticate 
an SMTP server whose server certificate has a domain name that is the 
domain name that the client thought it was connecting to." [RFC3207] 


MAY WISH TO 


The phrase "MAY WISH TO" indicates a behavior that might seem 
appealing to some people, but which is regarded as ridiculous or 
unnecessary by others. This phrase is frequently used to avoid 
further delay in approval of a document. 


For example: "Verifiers MAY wish to track testing mode results to 
assist the Signer." [RFC6376] 


COULD 


The phrase "COULD" provides a way for specification authors to 
articulate existential possibilities, in order to provide a hint that 
might be critical to reliable or secure operation, but without a hard 
requirement. The lack of a requirement allows for vendor product 
differentiation. 


For example: "An implementation could mitigate this race condition, 
for example, using timers." [RFC6733] 
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POSSIBLE 


The phrase "POSSIBLE" describes what some of the working group 
members thought of as an edge case that will never happen, but in 
practice allows the protocol to work at the most fundamental level. 


For example: "It is also possible for the server to send a completion 
response for some other command (if multiple commands are in 
progress), or untagged data." [RFC3501] 

MIGHT 


The phrase "MIGHT" conveys a requirement in an intentionally stealthy 
fashion, to facilitate product differentiation (cf. "COULD" above). 


For example: "In the case of audio and different "m" lines for 
different codecs, an implementation might decide to act as a mixer 
with the different incoming RTP sessions, which is the correct 
behavior." [RFC5888] 


Security Considerations 


Traditionally, security requirements in IETF documents have been 
expressed with a mixture of requirements words from RFC 2119 
[RFC2119] and the phrases used above. The key words in RFC 2119 are 
principally useful when threats and mitigations are clear and well 
defined. The key words in this document can be applied when the 
threat model is ambiguous, and mitigations are unclear or 
inconvenient. 
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